Maximizing Incident Response Automation for Investigations

Written by Intezer

    Share article
    FacebookTwitterLinkedInRedditCopy Link

    Top Blogs

    How does Intezer investigate alerts? Let’s zoom in on what happens during the investigation stage of Intezer’s Autonomous SOC solution, and how it fits into the incident response process for SOC teams.

    While we’ve provided an overview of Intezer’s entire Autonomous SOC process in a separate post, this blog aims to delve deeper into the investigation stage. This stage is critical and unique, as it enables Intezer to make smart decisions, provide recommendations for response, and forms the core technology that allows Intezer to reduce human involvement in the incident response process.

    Intezer’s ability to investigate evidence and cyber threats is designed to mimic the actions and logic of a reverse engineer and experienced SOC analyst. This allows security teams to use our Autonomous SOC solution like an extension of their team: triaging alerts, auto resolving false positives, and escalating findings about confirmed threats to the right people for incident response and mitigation.

    Automating Evidence Collection into the Investigation Pipeline

    Before any investigation can take place, Intezer collects all pieces of evidence associated with an alert to investigate them one-by-one. This can include files, command line parameters, process arguments, URLs, parent and child processes, memory images, and more. You can read more about the evidence collection stage in our earlier post about Intezer’s full incident response process.

    4 Steps of Automated Investigation Process for Incident Response

    The investigation part of Intezer’s incident response process can be broken down into four main steps:

    1. Analysis – Analyze each individual piece of evidence that was collected, such as files, command lines, URLs, and memory images, using multiple techniques and technologies. This includes recursively unpacking artifacts to extract more relevant evidence.
    2. Correlation – For each individual artifact, we find any code, behavior, and techniques similarities with any known malicious or trusted artifact in Intezer’s continuously growing database, and with any known artifact in the organizational database.
    3. Decision Making – We then combine and summarize all analysis results to assign a clear verdict, classification (threat actor / malware family / trusted software vendor), and risk for each individual piece of evidence.
    4. Triage Assessment – Finally, we build a cohesive alert-wide assessment, including a verdict (true / false positive), risk level, and recommended next steps for response. We form this assessment by leveraging AI models that combine the following information:
      1. Investigation results from each individual piece of evidence.
      2. Raw information and metadata from the security tool that originally fired the alert.
      3. All Indicators of Compromise (IOCs) and detection content from all evidence.

    In the following sections, we will delve into each part of the high-level investigation process in more detail. Overall, our objective is that Intezer is able to “think” like a SOC analyst, providing high-quality investigation results to your team in minutes.

    1. Analysis

    The analysis stage is the first step in the investigation process. Here, each individual artifact associated with an alert is thoroughly examined. Artifacts can include a wide range of evidence, such as files, command lines, URLs, and memory images. 

    The goal of the analysis stage is to understand the nature of each artifact and its potential implications. To achieve this, we employ multiple techniques and technologies, including:

    1. Sandboxing (dynamic analysis)
      1. Monitoring processes and process tree changes
      2. Monitoring network traffic including DNS, TCP, UDP and any associated IOC 
      3. Monitoring service creations
      4. Monitoring file system activity (read, deleted, written)
      5. Monitoring Windows registry activity (read, deleted, written)
      6. Monitoring memory manipulation and injection
    2. Disassembly of machine code and interpreter code
    3. Static code and behavior analysis (e.g. API calls)
    4. Memory analysis
    5. URL analysis – via reputation, behavior, phishing indicators, visual similarity, and more
    6. Configuration extraction
    7. Proprietary YARA rule repository
    8. String extraction
    9. File metadata and hash extraction
    10. Textual analysis using AI models (ChatGPT-like) – for scripts, macros, suspicious emails content, etc.
    behavior section of sandboxing/dynamic analysis report from Intezer's automated incident response process
    Example of a partial sandboxing/dynamic analysis report.
    static code analysis of evidence Intezer investigated
    Example of static code analysis which identified suspicious capabilities and correlated to certain types of known threats.
    Example of a disassembled module to machine code that was later correlated with a Formbook malware.

    In addition, one of the unique aspects of our analysis process is the use of recursive unpacking. Many threats attempt to hide their true nature by compressing, packing or encrypting their code. Recursive unpacking allows us to extract the hidden code and other items within these packed or encrypted artifacts, revealing more relevant evidence for further analysis. This is one of the ways Intezer can investigate evidence “deeper” than traditional tools or methods.

    Example of multiple unpacked modules, either injected in memory or dropped on disk.

    Analyzing Fileless Malware and In-Memory Threats

    In addition to file-based threats, a decent amount of alerts for most security teams are in fact “fileless.” That can include behavioral or ML-based alerts from EDR, living-off-the-land techniques such as command lines and Powershell scripts, and more. These alerts can be a pain for incident response teams to investigate or mitigate. Intezer analyzes those types of alerts with the following methods:

    1. Analyzing the textual information from the alert (such as command line, process arguments) – for example, a “curl http://malicious.web.site” command would trigger a URL analysis.
    2. Packaging and detonating a command line in our sandbox environment – such as analyzing a base64 encrypted powershell script within the command line.
    3. Collecting and analyzing any scripts that were executed.
    4. Conducting deep memory analysis on the suspected endpoint to identify any hidden code injections or other traces of a fileless threat.
    Example of a fileless alert fired by Crowdstrike’s Command and Scripting engine, which triggered Intezer’s automated memory analysis and identified Meterpreter malicious code in memory.

    By thoroughly investigating each individual artifact, we can gain a deep understanding of the alert and the potential threat it represents. This forms the foundation for the subsequent stages of the investigation process.

    2. Correlation

    In the correlation stage we compare all extracted data from the Analysis stage to known malicious or trusted artifacts. This can include correlating pieces of code, strings, behaviors, file paths and more. The correlation is done against three main sources:

    1. Intezer’s continuously growing global “genetic” database.
    2. Information from the organization itself (private genetic database).
    3. Third party threat intelligence and reputation sources.

    Genetic Analysis

    The most unique and important aspect of our correlation process is the use of Intezer’s proprietary Genetic Analysis technology. Essentially, this is a key component of what makes Intezer special.

    Our Genetic Analysis technology allows us to identify the “genes” – small pieces of code – that an artifact shares with known malware, legitimate software, or other code. By identifying these shared genes, we can determine if an artifact is related to known threats or trusted software and helps to identify the origin of any unknown threat.

    Example of a Genetic Analysis correlating thousands of pieces of code to other known Agent Tesla variants.

    The Genetic Analysis technology is particularly impactful because it allows us to identify even the smallest similarities between an artifact and known code. This means that even if a threat is new or has been modified to evade detection, we can still identify it based on its shared genes.

    Strings extracted from a file by Intezer for analysis and incident response
    Example of strings extracted from a file which were correlated to known variants of Iron Ransomware.

    Private, Organization-Specific Genetic Analysis Data

    In addition to Intezer’s global genetic database, which is constantly maintained by Intezer’s research team and numerous automatic software code-indexing processes, we also correlate artifacts with the organization-specific genetic database. This database is specific and private to each customer and it is populated automatically based on the organization’s data, as well as customer’s manual private indexing.  This is particularly helpful for identifying internally-developed software for the purpose of reducing false positives. It can also be helpful to identify any similar variants of unique, targeted threats that are indexed by the customer.

    genetic analysis of benign microsoft software by Intezer for incident response
    Example of a Genetic Analysis which clearly identifies a file as a trusted Microsoft software.

    Global Threat Intelligence and Reputation Databases

    In addition to our Genetic Analysis, Intezer also correlates every extracted piece of evidence with threat intelligence and reputation databases such as VirusTotal, and additional sources such as the MITRE ATT&CK framework to highlight any malicious techniques used.

    Through the correlation stage, we can gain a deeper understanding of each artifact and its potential implications, providing valuable context for the subsequent decision-making stage.

    3. Decision Making

    The decision-making stage is where we take the insights gained from the analysis and correlation stages and use them to make informed decisions about each individual piece of evidence.

    For each artifact, we assign a verdict. This verdict can categorize the artifact as malicious, trusted, or other categories based on the results of the previous stages.

    In addition to the verdict, we also assign a classification to each artifact. This classification can identify the artifact as part of a known malware family, associated with a specific threat actor, or as a product of a trusted software vendor. This classification provides further context for the alert, helping to understand the potential source and purpose of the threat.

    Calculating verdicts and classifications is usually not a trivial task, as each piece of evidence usually includes many different micro-artifacts with different classifications and verdicts of their own. For example, a certain file that was alerted upon in Crowdstrike can run Explorer.EXE and Powershell.EXE, and while they are a trusted Windows file, that should not impact the overall verdict of the original file. Automating this non-trivial task is critical for reducing human involvement in alert triage processes.

    The decision-making stage is a crucial part of the investigation process. By assigning a verdict and classification to each piece of evidence, we can provide a clear and actionable assessment of each alert. This forms the basis for the triage assessment and the subsequent response stage.

    4. Triage Assessment

    The alert triage assessment is the final step in the investigation process. Here, we use AI models to combine all the information gathered in the previous stages to build a cohesive alert-wide assessment.

    The goal of the alert triage assessment is to provide a verdict (true/false positive), risk level, and recommended next steps for response. This assessment provides a clear and actionable summary of the alert, allowing your security team to respond effectively and efficiently, ensuring they have all the information they need to make informed decisions about each alert.

    For calculating the overall assessment, our algorithm combines:

    1. Analysis results from each individual piece of evidence: These results, which include the verdict and classification assigned in the decision-making stage, provide a detailed understanding of each piece of evidence associated with the alert.
    2. Deep, raw information from the security tool that originally fired the alert: This information provides additional context for the alert, helping to understand the circumstances under which it was triggered.
    3. All Indicators of Compromise (IOCs) and detection content from all evidence: These IOCs and detection content provide actionable information that can be used to respond to the alert.

    Once the alert triage assessment is complete, it can be seen either in Intezer’s alert report, inside your security tool that fired the alert, or alternatively via API. It also can drive next steps and automated remediation or other workflows, as described in our article about the other stages in Intezer’s Autonomous SOC process.

    Intezer's alert report with findings and recommendations for incident response
    Alert Report which contains the full triage assessment.

    Trust and Visibility into Automated Decisions for Incident Response

    What about when AI and automated tools make decisions that just don’t make sense? In cybersecurity, it’s critical that we can trust the findings we get from an investigation. Incident response teams don’t have time for vague or confusing reports. We need information so we can respond quickly to active cyber attacks, to fully contain and eradicate the threat.

    Building trust with our customers means being transparent, so you don’t worry or feel like Intezer is a mysterious “black box” spitting out information you can’t understand.

    Our Autonomous SOC Report gives you an executive summary about the previous week, so you can understand at a high level how Intezer is performing and responding to your alerts. False positives and auto remediated alerts aren’t hidden. While it can be an overwhelming amount of information, Intezer is also designed to display findings from its investigations. If you need to understand why Intezer marked a threat as a false positive or a confirmed threat, you have access to everything. You get sandbox reports on individual files, website images of a scanned URL, the full JavaScript content extracted and summarized by Intezer’s AI Insights, and other key analysis information.

    We also strive to make sure that our team can explain Intezer’s results, understand the algorithms we’ve built, and incorporate AI responsibly in our platform. Our team takes customer feedback and support seriously too. Our AI Insights features include thumbs up/down buttons for quick feedback on the summaries we generate using Large Language Models. Our analysis reports include a “Report Analysis” option if there is something looks like an error or issue that our team should review. For teams that want access to additional expertise — when you need another person to take a look ASAP — our Complete plan includes on-demand support so our expert security analysts can help you investigate further.

    Test Running Automation in Your Incident Response Process

    We know that Intezer has to prove itself to you.

    We make some big claims about what Intezer can do and it’s understandable that teams want to test run our Autonomous SOC solution for themselves. That’s why we offer a trial of our Complete plan, so you can try Intezer for free. We also publish screenshots, videos, webinars, FAQs, and documentation so you can find answers to any of your questions about how Intezer works.

    More questions? Want to see how it works for yourself? Discover how Intezer can automate incident response process — reach out to schedule a demo now.

    Intezer

    Count on Intezer’s Autonomous SOC solution to handle the security operations grunt work.

    Generic filters
    Exact matches only
    Search in title
    Search in content
    Search in excerpt